Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000086_owner-urn-ietf _Fri Mar 28 18:51:39 1997.msg

Internet Message Format | 1997-04-01 | 13KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id SAA06009
    for urn-ietf-out; Fri, 28 Mar 1997 18:51:39 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id SAA06004
    for <[e-mail]>; Fri, 28 Mar 1997 18:51:35 -0500 (EST)
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA19138  (mail destined for [e-mail]); Fri, 28 Mar 97 18:51:32 -0500
Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id QAA11451; Fri, 28 Mar 1997 16:51:28 -0700 (MST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 28 Mar 1997 16:50:20 -0700
To: Dan Connolly <[e-mail]>
From: "Ron Daniel, Jr." <[e-mail]>
Subject: Re: [URN] resend of draft-urn-resolution-services-01.txt
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Reply-To: "Ron Daniel, Jr." <[e-mail]>
Errors-To: [e-mail]

At 04:06 PM 3/28/97 -0600, Dan Connolly wrote:
>Ron Daniel, Jr. wrote:


>there seem to be
>five sorts of things: names (N), locations (L), identifers (I),
>resource instances (R) and URCs (C). It seems like there are only
>finitely many interesting permutations.

Sure, but this argument rests on two assumptions:
  1) There are only five things
  2) only some permutations are interesting

The second one is not crucial, its only a compactness sort of thing.
I'm not really comfortable with the idea of stating that our information
universe is composed out of 5 elements.  Maybe it is, but I suspect not.
Just as N and L are specializations of I, we could look for specializations
of R (versions, translations,... spring to mind). Do we need to distinguish
them? If we set extension rules we can argue that later and cope with the
stuff for our immediate needs now.

>Say... that reminds me: what about C2R, C2I, C2N, C2L?

Yeah, they would be useful, but I am not ready to propose
something on how to handle all the problems of dealing with
format and schema differences of the incoming URC, specifying
the format and schema for the outgoing URC (or type for
resources, etc.), and the real bear of the query language
that the '2' expands into. I wanted to get the quick wins
out of this and deal with the harder stuff some other time.


>If the list is extensible, it's extremely important to
>specify what to do when you find an unknown operation and in
>general, how new operations get deployed. I'll
>have to look at the NAPTR draft etc. to be sure this
>is covered.

NAPTR can handle this 2 ways. I prefer the first. Servers advertise
the services they can provide, clients know the ones they can support.
So, there is no backward incompatability problem with servers offering
new services, clients know they can't handle them and don't ask for them.
(We may need to mandate that clients MUST NOT try to deal with unknown
services, it was probably an unspoken assumption of mine). The only
problem is if we don't have a controlled list of the services, in that
case we could have incompatible interpretations of the same label. Michael's
document probably needs to be augmented with an IANA list.

If this is not satisfactory, then the second way is to use a new flag
to indicate the presence of extended service definitions. The NAPTR spec
states that clients MUST ignore records with an unknown flag. However,
we could burn a lot of flags if the extensions come in dribs and drabs.


>> >Note that N and L are both URIs. Hence my second point:
>> >the distinction between URNs and URLs isn't necessary.
>>
>> Yes and no. Both are URIs, so an I2I method would suffice at that level.
>> However, this group distinguishes between names and addresses.
>
>Yes, there are very useful _extrinsic_ distinctions between names
>and addresses: external to the identifier, there might be
>information that suggests it can be resolved or not, etc. I just
>object to a separation of the space of URL schemes and
>the space of URN schemes and to the separation of URL syntax
>from URN syntax.

I'll take that up in a seperate message. For now I will assume we
continue to distinguish between the two, and we want a syntactic
handle (urn:) to aid in the quick discrimination of them.

>> If I have
>> a name and want to get an address, we need an N2L operation.
>
>I don't dispute the utility of a N2L operation: I just don't
>see any reason to restrict the input to URNs.

OK, here I think we can agree. I don't see a lot of useful difference
between L2L and N2L, so the operations of I2L, I2N, I2C, I2R (and their
plural forms) may be sufficient. We can also have I2I, I2Is for when
we don't need to maintain the distinction on the output.

>> >> 4.2 N2Ls (URN to URLs)
>> >> This operation is used to map a single URN to 0 or more URLs.
>> >
>> >
>> >This one becomes:
>> >       Given a URI N, Return a set of URIs L[i] such that there
>> >       is a link from N to L[i] of type "N2L" for each i.
>>
>> I'm sorry Dan, but I really don't see the benefit of your suggested
>> rewordings.
>
>It's mostly a matter of taste.

Actually I should have revisited my remark after I had gotten further into
your reply. When you suggest the generic relationship thing then the
notation offers some benefit.

>But there is a little substance
>to it: I expect this document to specify not just black-box
>operations, but also some properties of those operations that
>relate the operations to each other.

But the notation doesn't state those properties, it only states
that a link of type "N2L" or whatever exists. The description of
properties still has to be supplied. We can look int providing
such descrption of properties in the revision of the draft.

>For example, there seems to be, latent in the services-01 draft,
>a relation
>    N2L <: URI x URI
>that relates the N2L and the N2Ls operations: if computing
>N2L(n) yields l, then the pair (n,l) is in the N2L relation;
>meanwhile, if N2Ls(n) yields l[i], then (n, l[i]) is in the N2L
>relation for each i. This connection is implied by the naming
>etc., but not specified explicitly anywhere.

Agreed. Such notation is not my normal mode of expression, but
the next version of the draft should state this one way or another.

>RFC1630 is informational, not standards track. I suggest you
>cite either the url syntax draft, or RFC1808, which I expect
>will be updated/replaced by the ultimate url syntax draft.

The problem is that RFC 1630 sets the model of URIs being the
superset of URNs and URLs. The other documents you specify
standardize URLs. I am unaware of a standards-track URI
specification.

[On the subject of metadata schemas, formats, ...]


>> THTTP says that people should use format negotiation if they want
>> a partiular format. We are not defining the one true URC format.
>
>Sure... but the MIME type of the result isn't the same as
>the schema.

Whoops. Of course. My error.

> Lots of metadata schemas can be represented
>as text/sgml. Or do you intend to fold the mime-type axis
>and the schema axis into one?

Certainly not. Somewhere there is a statement that IMTs are not to
represent schemas.

I had been assuming that the URC return format would indicate the
schema it followed. If we need to extend the model so that the
client can ask the server to provide the URC in a particular
schema, I think we need some serious discussion on that topic.

>And about PICS... it specifies ways to encode metadata
>requests into HTTP GET operations. Seems to me THTTP is
>doing the same thing. If they can do it the same way,
>that seems like a Good Thing. I still haven't gotten
>around to THTTP yet.

and I haven't gotten around to catching up on the latest stuff
with PICS. However, I doubt they are the same ways. THTTP is
not intended to be standards-track. A real standards-track
document on how to use HTTP to talk with a resolver should
probably make I2L, I2C, ... into new methods. THTTP is a
trivial way to do it with GET. It lets us do experiments now
with NAPTR, which is a more serious proposal. (It is also
targeted for experimental, but for different reasons).


>> >Something that I think should be specified: is L2N expected
>> >to be the inverse of N2L?
>>
>> Nope. If a resource has multiple URNs and URLs, I don't think we should
>> mandate any particular behavior on the part of resolvers to make stronger
>> mappings between the identifiers.
>
>I said 'expected,' not mandated. You really mean that there's
>no relationship whatsoever between the N2L and the L2N operations?

None that I wish to specify.

I expect resolvers to do a variety of things with N2L. They may
try to return the "closest" URL to the client, or one at random,
etc. Given that a resolver has a set of URNs and URLs for a single
resource, I don't want to require that n = L2N(N2L(n)), and I
don't particularly want to suggest it as expected behavior. In
fact, I would be more inclined to warn client implementors that
they should not assume it.


>> >> 4.8 L2Ls (URL to URLs)
>> >> This operation is used to discover URLs that are considered equal to
each
>> >> other.
>> >
>> >This one is clearly supposed to be an equivalence relation.
>> >If N2N is also an equivalence relation, then I don't understand
>> >the distiction.
>>
>> See earlier discussions on names vs. addresses.
>
>I don't see that it applies. Could you elaborate?


Its just a simple permutation of N and L. We added the I2L and other
operations with I at the last minute. With your recent suggestions
we will probably use I2N and I2L instead of N2N, N2L, N2I, L2L, N2N, L2I.


>If there's an I2I operation, why is L2L necessary? why is
>N2N necessary?


Because we want control over the output forms of the I. Sometimes
we want an address and sometimes we want a name. Distinguishing the
input types doesn't seem so important since they can be self-describing
because of the URN prefix.

> It seems clear to me that if n is a URN
>and l is a URL, then you can be certain that I2I(n) won't
>return l and vice versa.

That is not at all clear to me. In fact, the converse is what seems
clear to me. If we say "map this I to another I", and we say that
Ns and Ls are both instances of I, then we should expect either as
a result.

>The relationship between two URLs that are equivalent
>is identical to the relationship between two URNs that
>are equivalent. What motivates three different operations
>to deal with this one relationship?

I currently think that I2L, I2N, and I2I are the minimal set if
we want to maintain the axiomatic distinction between Ns and Ls.
What do you think now?

>> >       S2D(URI S, URI T) -> set of URIs D[i]
>>
>> Hmmm, sounds pretty good. The first question that comes up is that
>> sometimes we are happy mapping from one URI to another, and other times
>> we want to get back a specific type of URI (URN or URL). So, we need to
>> modify your earlier definition and this suggestion for the generic
>> operation.
>
>I'll buy that; so you might call them IT2I, IT2L, and IT2I.
>(for identifery/type to identifer, ...).

We may want to take this idea further in other messages, but not this one.
Its already too long.


>> >> 4.10 I2I (URI to URI):
[Dan states he thinks it is unneeded and wants to...]
>try yet another argument:
>
>Suppose we had relations:
>    N2N <: URN x URN
>and
>    L2L <: URL x URL
>
>If the intersection of URNs and URLs is empty (fair assumption?)
>then N2N and L2L don't intersect. So one relation I2I that
>is the union of L2L and N2N holds all the information from
>both relations without creating any ambiguity.

OK, here's the gap in our models. You seem to assume that URNs
and URLs are partitioned to such an extent that providing a URN
(or URL) as an input to I2I automatically restricts the output of
the operation to the input type. I don't. I assume that
a resolver has a set of URNs and a set of URLs, but that sometimes
we won't care about keeping them distinct. When we don't care,
we say "I" and either a URL or URN is fine.

>> >> 4.11 I=I (Is URI equal to URI):
>But again: the relationship between I=I and I2I should be
>specified, but isn't. For example, if I2I(x) yields y, then
>I would expect I=I(x,y) to return true, right?

Yes. We need to add these descriptions.




Ron Daniel Jr.              voice:[phone]
Advanced Computing Lab        fax:[phone]
MS B287                     email:[e-mail]
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545